Related issues:

• CMake warning when using FetchContent #1301
• Cut a new release of yaml-cpp #1335

Be aware that the warning from #1301 won't go away with this merge request. Newer versions of CMake will emit a deprecation warning for CMake versions older than 3.10. It wanted, I can provide a different merge request bumping the minimum required version to CMake 3.10.

Be aware that the warning from #1301 won't go away with this merge request. Newer versions of CMake will emit a deprecation warning for CMake versions older than 3.10.

With the following declaration, I can't see any version warning with CMake 4.0 running in a MSYS2 environment ??

FetchContent_Declare(
  yaml-cpp
  GIT_REPOSITORY https://github.com/gruenich/yaml-cpp
  GIT_TAG        fac0bd8eb5c4972f4284ddebd20c5facb47a32e5
)

The warning (and error in CMake 4.0) is based on the <max> value in cmake_minimum_required not the <min> (unless a max isn't given obviously). So the warning mentioned would only appear if building with tests enabled since Google Test hasn't adopted the range syntax. For what it's worth setting CMAKE_POLICY_VERSION_MINIMUM prior to adding a third party projects like Google Test is one of the stated use cases in the documentation for that variable.

Not personally attached to CMake 3.4 or anything like that, just trying to fight the seeming misinformation that Kitware is forcing the minimum to be raised. As the warning/error itself states, you just need to adopt the new policies which is what the range syntax does.

Be aware that the warning from #1301 won't go away with this merge request. Newer versions of CMake will emit a deprecation warning for CMake versions older than 3.10. It wanted, I can provide a different merge request bumping the minimum required version to CMake 3.10.

Please make sure to bump the min. req. version to 3.10 to make it compatible with CMake 3.31.

@jbeder Can you please review?

Please make sure to bump the min. req. version to 3.10

It's the max version that matters, not the min version. Max above 3.10 will produce no warning currently.

It's the max version that matters, not the min version. Max above 3.10 will produce no warning currently.

No. CMake 3.5 is considered outdated and CMake 4.0 refuses to work with it as a minimum required version by default. Increasing the mininmum version is the right thing to do.

Setting a max version is ignoring the behavior of newer CMakes. Setting a max at or 3.30 (not 3.10) will silence the deprecation warning. It is no long-term solution, it is just looking away.

No, that is not true. CMake only cares about your maximum version, because what it really cares about is the policies. CMake does not refuse to work with a minimum version of <3.5. It refuses to work with a maximum version of <3.5, since that means you need <3.5 policies, and those polices were removed in CMake 4.0. If you don't set a maximum version, then it's based on the minimum version (because that's also the maximum version).

The maximum version sets the policies to that version. If your project builds with those policies, then you will be supported until CMake drops support for those polices. So setting 3.30 as the maximum version means you'll be supported until all the policies from 3.30 and earlier are removed.

This will be supported:

cmake_minimum_required(VERSION 2.12...4.0)

Much, much longer than this will be:

cmake_minimum_required(VERSION 3.5...3.9)

In fact, it will be supported exactly as long as:

cmake_minimum_required(VERSION 4.0)

(The downside of a large range is you need to test both ends of it, and you don't get to use newer CMake features, and there are a ton of great CMake features, especially in 3.24 with the ability to find a package or download it if it's not found!)

Henry, you are wrong.

1. We don't need to set the max version to 3.10, 3.30 is enough as 3.31 deprecated 3.10 and below.
2. Setting a max version is suppressing any indication from newer versions, that something got deprecated. It is better to have to adjust from time to time, as intended by the CMake project and not wait until something breaks for users without an easy fix.
3. Increasing the minimum required version to 3.5 and later 3.10 is the right thing. There is no need to stick to 9 years old software.

To be clear, I highly recommend increasing the minimum version; even 3.10 is really old. I think what you've done in this PR is perfect for starters. But the upper bound is not a "means to suppress" warnings. It is an indication of what you've tested on. It changes the policies just like the minimum version by itself would do. CMake sets the policies to the highest version in the range that it supports. The min version literally doesn't matter. You can set 2.6 as your min version for all CMake cares if you have a max version.

For example, in 3.27, they "removed" the FindPythonLibs module. That means if you set your maximum version to 3.27 or later, then the FindPythonLibs module will be gone when running on those versions of CMake. If you have your maximum version lower than 3.27, though, then that "missing" module will still be there, since CMake will never change your build when upgrading the CMake version you are running with after the maximum version it knows you've tested with.

1. Max version has nothing to do with when things got deprecated. You can set it to 4.0 as long as you try 4.0 with the 4.0 setting enabled and it works.
2. I'm a CMake contributor and maintainer for things like the Python distribution of CMake, and I don't know what you mean by "as intended by CMake". If you only have a minimum, yes, it should be updated regularly. If you have a maximum, the minimum is completely ignored. In fact, there's no guarantee at all that it even works with that version, you have to test it. The versions only control policies.
3. Fully agree, in fact, I think at least 3.15 is good.

Here's my current recommendation, copied from my Modern CMake book, which I updated when 4.0 was released:

• 3.24: The package finding system is great, good minimum to support package authors.
• 3.18: Pretty good support for Python and CUDA, most systems have at least this.
• 3.15: This is as low as most projects should go, Ubuntu 20.04+ has 3.16+.
• 3.10: Lowest version to avoid a CMake warning, Ubuntu 18.04+.
• 3.5: If you really need it.

As long as you set a maximum version, you can even set minimums below this. But don’t.

@henryiii I finally got around to skimming this thread, and since you're an expert, can you tell me either:

1. Accept this PR as-is.
2. Accept a different PR (I'll accept blindly anything you submit, given that you're an expert).

I am not reviewing the google test changes (which sound great, but it's nearly 300 files so I'm just assuming it's good), but the CMake updates look great and are thorough. As long as you have CI that use a reasonably recent version of CMake, I think it's great, though a followup could probably bump the min to 3.10 or 3.15 and the max to 4.0. Having a CI run with the minimum and the maximum is a good idea. You don't have to go as far as pybind11 were we run the configure step with every single version in the range, though. :)

FYI, 3.12 added CONFIGURE_DEPENDS to GLOB, I notice #1349 mentions globbing, so updating to 3.15+ in a followup would allow you to use CONFIGURE_DEPENDS to improve the behavior of globbing (you can also get rid of globbing, but I like to at least compare the hard-coded list with a glob, to help catch added files that are forgotten in the hard-coded list).

You can see a high level overview of what's new in each version here.

Thanks for merging! Do you consider creating a new version of yaml-cpp to help packagers with getting the new required CMake version?

Further, I created #1358 to follow up on Henry's suggestion to require CMake 3.15..4.0.